home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93c.txt / 000086_icon-group-sender _Fri Nov 12 21:30:33 1993.msg < prev    next >
Internet Message Format  |  1994-02-02  |  1KB
  1. Received: by cheltenham.cs.arizona.edu; Sat, 13 Nov 1993 16:50:04 MST
  2. Date: Fri, 12 Nov 93 21:30:33 CST
  3. From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery)
  4. Message-Id: <9311130330.AA14375@runner.utsa.edu>
  5. To: icon-group@cs.arizona.edu
  6. In-Reply-To: <1993Nov3.105756.909@sics.se> (pipex!uknet!mcsun!sunic!sics.se!sics.se!soder@uunet.uu.net)
  7. Subject: Re: Icon debugging and MT-Icon
  8. Content-Length: 830
  9. Status: R
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. >   Hakan Soderstrom writes:
  13. >   Knowing next to nothing about MT-Icon, my question is: Will MT-Icon
  14. >   obviate the need for other debugging extensions to Icon?
  15.  
  16. Yes, MT Icon is intended to allow the construction of debuggers for Icon
  17. in Icon.  An Icon program can load another Icon program (producing a
  18. co-expression value corresponding to a call to its main() procedure),
  19. and then control its execution, inspect and modify its variables, etc.
  20. Execution control is driven by an event model.
  21.  
  22. We have mostly used it so far for program visualization tools, and there
  23. are one or two things (like variable traps) I'd like to add especially
  24. for debugging, but the code for MT Icon and monitoring has been used for
  25. some time now by a number of people.
  26.  
  27. Clint Jeffery, jeffery@ringer.cs.utsa.edu
  28. The University of Texas at San Antonio
  29.